1. Field of the Invention
The present invention relates to a method and apparatus for recording digital data streams and their management information, which record digital data transport stream units such as application packets in predetermined-sized sectors of a disk-type recording medium such as a digital versatile disk (referred as ‘DVD’ hereinafter) and which create and record the management information for the recorded transport stream units.
2. Description of the Related Art
In the conventional analog television broadcast, video signals are transmitted over the air or through cables after being AM or FM modulated. With the recent advance of digital technologies such as digital image compression or digital modulation/demodulation, standardization for digital television broadcast is in rapid progress. Based upon the Moving Picture Experts Group (MPEG) format, satellite and cable broadcast industry also moves towards the digital broadcast.
The digital broadcast offers several advantages that its analog counterpart cannot provide. For example, the digital broadcast is capable of providing services with far more improved video/audio quality, transmitting several different programs within a fixed bandwidth, and offering enhanced compatibility with digital communication media or digital storage media.
In the digital broadcast, a plurality of programs encoded based upon the MPEG format are multiplexed into transport streams before transmitted. The transmitted transport streams are received by a set top box at the receiver and demultiplexed into original programs. If a program is chosen among the demultiplexed programs, the chosen program is decoded by a decoder in the set top box and original audio and video signals are retrieved. The retrieved audio and video signals are then presented by an A/V output apparatus such as a TV.
FIG. 1 depicts a block diagram of a general digital data stream recording system which includes a set top box 100, a communication interface such as IEEE-1394, and a streamer 200. The set top box 100 receives transport streams, in which several programs are multiplexed and encoded by data encoders equipped in broadcasting stations, and demultiplexes the received transport streams. After a data decoder 120 in the set top box 100 decodes the transport streams corresponding to a program tuned by a tuning unit 110 under the control of a microcomputer 140 to process a request from a user, it outputs the decoded transport streams to an A/V device such as a TV set for presentation. The set top box 100 may transmit the transport streams corresponding to a program chosen by a user to the streamer 200 through the IEEE-1394 interface so that the transport streams corresponding to the chosen program are recorded on a recording medium 230 such as a recordable DVD by the streamer 200.
According to another request from a user, the set top box 100 may receive a recorded program reproduced from the recording medium 230 by the streamer 200 through the IEEE-1394 communication interface, then the received program is presented on a TV set after being decoded by the decoder 120 in the set top box 100.
Meanwhile, for recording received digital broadcast signals on a recording medium, it is necessary to develop schemes for writing the received digital data streams in sectors of fixed size, organizing them on the recording medium, and creating management information for the recorded digital streams. However, no international definite standard for such schemes is available yet and thus various methods have been proposed by relevant developers.
One of the proposed methods for recording digital data streams and creating their management information will be explained with reference to accompanying drawings.
FIG. 2 depicts the recording syntax for digital data streams. A stream object (SOB), which is a recorded object created by a one-time recording, includes a plurality of stream object units (SOBUs), and each SOBU is recorded in a plurality of sectors. A single sector, whose size is 2048 bytes, can accept a plurality of application packets (APs) whose size is 192 bytes and header information HDRS regarding the written application packets. The AP includes a 4-byte time stamp indicating the packet arrival time and a 188-byte data packet.
Therefore, a 2048-byte sector may be filled with a header information HDRS, several application packets (APs), and null data area if necessary, as shown in FIG. 2. The area filled with null data is called as padding area and its size varies.
FIG. 3 shows the format of the application header information and application header extension information recorded in the header information HDRS. The application header information contains information on a plurality of application packets recorded in its own sector, and it comprises a field indicating a version of the header format, a field AP_NS indicating the number of application packets, and so on. The application header extension information, which is optional, requires 1 byte for each application packet recorded in its own sector, and it comprises fields AU_Start (Access Unit Start) and AU_End (Access Unit End) indicating whether a packet belongs to starting and ending of data stream unit such as Infra-coded picture (referred as ‘I-Picture’ hereinafter) data which is accessible at random, respectively; a reserved field; and a field for copyright.
FIG. 4 shows a digital stream recording example by a recently proposed method for recording application packets in sectors. The method of FIG. 4 divides an application packet into two parts if the remaining area of a sector cannot accept a single application packet, and records the first part whose size is equal to the remaining area in the current sector and the second part in the next sector. However, the remaining area of the last sector belonging to a SOB is filled with null data. According to this method, a 2048-byte sector can be wholly used as recording area except the last sector.
The recording example of FIG. 4 is explained in more detail to make the recently proposed method be understood better.
Since the remaining area of the sector M-2 is smaller than a single AP, a 192-byte AP is divided into 130-byte and 62-byte parts. The first 130-byte part of the divided application packet is recorded as the last recorded packet APM-2 #10 of the sector M-2 and the second 62-byte part is recorded as the first recorded packet APM-1 #1 of the sector M-1. Then, 10-byte application header extension information for all application packets recorded in the sector M-2 including the partial application packet APM-2 #10 is created and recorded in the header area HDRS of the sector M-2, and a value of 00001010b (10 in decimal) is written in the field AP_NS of the application header information.
Meanwhile, the sector M-1 contains the second 62-byte part as the first recorded packet APM-1 #1 and 10 application packets APM-1 #2 to #11 whose 192-byte data are all recorded in the sector M-1, 54-byte (=14+14+1+15) header information which is explained above referring to FIG. 3, and 11-byte application header extension information which is generated and recorded for 11 application packets, so that 2047 bytes (=62+1920+54+11) of the sector M-1 are used for data recording and 1 byte remains in the sector M-1.
Accordingly, to use the whole 2048-byte sector, the next application packet of 192 bytes should be divided into 1 byte and 191 bytes, and 1-byte new application header extension information corresponding to the application packet whose the leading 1 byte is to be recorded in the sector M-1 should be generated and added in the sector M-1.
However, if 1-byte application header extension information is added in the sector M-1, the sector becomes full and the next application packet to be divided should be recorded in the next sector M. In this case, the application packet recorded in the sector M corresponds to the header extension information which is recorded in the different sector, and there occurs a problem for recording the number of packets recorded in one sector. That is, if the number of the APs recorded in the sector M-1 is written in the packet number field AP_NS, the written number is not equal to the number of header extension information in that sector, and if the number of header extension information is written in the field AP_NS, the written number is different from the number of the APs recorded fully and partially in that sector.
To avoid such problems, the 1-byte header extension information should be inevitably recorded in the next sector M. However, if the 1-byte header extension information is recorded in the next sector M, the sector M-1 leaves 1 byte unused, which causes mismatch with the provisional standard specification of stream recording that a sector is fully used without unwritten area if the sector is not the final one of a SOB.